System and apparatus for dynamically upgrading concentrated executable computer software code

ABSTRACT

In dynamically upgrading an original concentrated executable computer software code with an upgrade bytecode, list processing and indexing is used to create indexes of various code structures within the upgrade bytecode. Preferably, index listings for each of the code structures are created. The index listings contain listings of identifiers corresponding to the particular instances of the respective code structures in the upgrade bytecode and index references corresponding to each of the identifiers included in the listing. The upgrade bytecode is reduced in size by replacing identifiers representing code structures in the upgrade bytecode with the corresponding index references. The concentrated upgrade bytecode is then integrated with the original concentrated bytecode, and the index listings formed during concentration of the upgrade bytecode are added to the virtual table as a record. Amendments are made to other index listings included in a virtual table to facilitate execution of the upgrade bytecode in conjunction with the original concentrated computer software code.

FIELD OF THE INVENTION

[0001] The present invention relates to a system and apparatus fordynamically upgrading concentrated executable computer software code.The invention is particularly useful in upgrading bytecode and computersoftware written in an object-oriented language, such as JAVA.

DICTIONARY

[0002] The following dictionary is to be used in interpreting thisspecification:

[0003] “bytecode” is computer software code.

[0004] “class”, or “classes”, are code segments that contain methoddefinitions and field specifications.

[0005] “comprise”, or variations such as “comprises” or “comprising”,will be understood to imply the inclusion of a stated integer or groupof integers but not the exclusion of any other integer or group ofintegers.

[0006] “electronic communications network” or “ECN” will be understoodto include any computing, multimedia or video system in which a user canremotely access or receive transmissions of bytecode.

[0007] “field” is a component of an object in which object data arestored as integers or characters, i.e., variables.

[0008] “identifier” means a reference to the name of a unique class,method or field.

[0009] “instance”, when used in the context of data, refers to dataassociated with an object.

[0010] “method” is code used to perform a particular task, such asmodifying data in some way, such as for performing a procedure or afunction.

[0011] “object” is a collection of fields and methods that operate onfields. An object is also an instance of a class.

[0012] “private”, when used in the context of data, refers to datagenerally accessible by a single class.

[0013] “public”, when used in the context of data, refers to dataaccessible by multiple classes.

[0014] “static”, when used in the context of data, refers to dataassociated with each class.

BACKGROUND OF THE INVENTION

[0015] In U.S. Pat. No. 6,163,780, Hewlett-Packard Company of Palo Alto,Calif., describes a system for concentrating executable computersoftware code. This system involves parsing the computer software codeby means of concentrating software. The concentrating software achievesthis by a series of scans of the computer software code.

[0016] The first scan identifies all unique classes referenced in thecomputer software code and includes the identifier of each such classinto a “ClassList”. The second scan searches for all unique methods (theidentifiers of which are stored in a “MethodList”) and the third scansearches for all unique Fields (the identifiers of which are stored in a“FieldList”).

[0017] Every class identified in the ClassList is then scanned todetermine whether there are references to further classes not recordedin the ClassList. If so, then the identifier for such classes is addedto the ClassList. The process is then repeated in relation to the newlyadded classes. In this manner, all unique classes referenced in thecomputer software code are identified in the ClassList.

[0018] Once this scan has been completed, every class in the ClassListis again scanned, but this time to determine any further methods notrecorded in the MethodList. If a method is found that is not included inthe MethodList, then the identifier for the method is added to theMethodList. The process continues until all classes in the ClassListhave been scanned for further methods.

[0019] A further scan is used to identify all further fields notincluded in the FieldList and add their identifier to the FieldList.This scan involves traversing all classes in the ClassList and everymethod in these classes to identify further fields.

[0020] The ClassList, MethodList and FieldList are then each sorted andreformatted into a canonical list form. Each class, method and field inthe ClassList, MethodList and FieldList, respectively, is also assigneda unique index reference (typically an integer corresponding to theposition of the corresponding identifier within the appropriatecanonical list).

[0021] Local data referenced by each method of each class are thenstored in an array for each class. The local data reference in eachmethod is then replaced with the index value of the location of thelocal data in the array. The computer software code can then be executedwith class, method and field invocations being resolved as part of theexecution process.

[0022] The problem with this arrangement is that the use of indexreferences to corresponding canonical lists hinders upgrading of thecomputer software code. To elaborate, the computer software code is inconcentrated form while, typically, the upgrade bytecode will not.However, if the upgrade bytecode is in concentrated form, there is noguarantee that the canonical lists formed from concentration of theupgrade bytecode will be compatible with the canonical lists formed fromconcentration of the computer software code. There is also no mechanismfor allowing the computer software code to be dynamically upgraded.

[0023] Accordingly, there is a need to allow concentrated computersoftware code to be dynamically upgraded without the need toreconcentrate the computer software code.

SUMMARY OF THE INVENTION

[0024] An object of the present invention is to provide a system fordynamically upgrading concentrated bytecode. The present invention alsoprovides a system and method for interpreting and executing adynamically upgraded version of the concentrated bytecode.

[0025] It is another object of the present invention to provide a systemand method for receiving bytecode comprising the upgrade, concentratingit, transmitting it via a computer network, such as the Internet, andintegrating the concentrated bytecode comprising the upgrade with theoriginal concentrated bytecode by means of a virtual table.

[0026] By providing a method and system for dynamically upgradingbytecode or computer code, the present invention alleviates to a greatextent the need to reconcentrate bytecode or computer code when thebytecode or computer code needs to be upgraded. It also allows thebytecode to be upgraded “on-the-fly”.

[0027] In a preferred embodiment, list processing and indexing is usedto create indexes of various code structures within an upgrade bytecode.Preferably, index listings for each of the code structures are created.The index listings contain listings of identifiers corresponding to theparticular instances of the respective code structures in the upgradebytecode and index references corresponding to each of the identifiersincluded in the listing. The upgrade bytecode is reduced in size byreplacing identifiers representing code structures in the upgradebytecode with the corresponding index references. The concentratedupgrade bytecode is then integrated with the original concentratedbytecode, and the index listings formed during concentration of theupgrade bytecode are added to the virtual table as a record. Amendmentsare made to other index listings included in the virtual table tofacilitate execution of the upgrade bytecode in conjunction with theoriginal computer software code.

[0028] More particularly, in an embodiment applicable to typicalJAVA-based computer code, or bytecode, the data structures includeclasses, method and fields. Listings of the classes, methods and/orfields appearing in the JAVA bytecode are created by systematicallyreviewing the JAVA upgrade bytecode to identify each instance of aparticular class, method and/or field, respectively. These listings aresorted to create respective canonical listings or indexes of theclasses, methods and/or fields invoked in the upgrade bytecode. Theselistings include reference indicators such as index locations orpointers, assigned to each of the classes, methods and/or fields in therespective sorted lists. The JAVA upgrade bytecode is then revised sothat the index locations of the classes, methods and/or fields replacethe identifiers of the class, methods and/or fields invoked in theupgrade bytecode. The sorted lists are then added to the virtual tableas a record and amendments made to previous index listings included inthe virtual table to facilitate execution of the upgrade bytecode inconjunction with the original computer software code.

[0029] The present invention also provides an interpreter for use inconjunction with the combination of the concentrated upgrade bytecodeand the concentrated original bytecode. The interpreter of the presentinvention can execute bytecode concentrated in accordance with theconcentration method or system of the present invention when combinedwith the concentration method or system of the invention described inU.S. Pat. No. 6,163,780.

[0030] These and other features of the invention will be appreciatedfrom review of the following detailed description of the invention,along with the accompanying figures, in which like reference charactersrefer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031]FIG. 1 is a block diagram illustrating an electroniccommunications network and server systems in accordance with the presentinvention.

[0032]FIG. 2 is a system block diagram in accordance with the presentinvention.

[0033] FIGS. 3A-3C are illustrations of various storage media upon whichimplementing code in accordance with the present invention can bestored.

[0034]FIG. 4 is a flow diagram of a method of concentrating software inaccordance with the invention described in U.S. Pat. No. 6,163,780.

[0035]FIG. 5 is a flow diagram illustrating a first phase of a method ofconcentrating software in accordance with the invention described inU.S. Pat. No. 6,163,780.

[0036]FIG. 6 is a flow diagram illustrating a second phase of a methodof concentrating software in accordance with the invention described inU.S. Pat. No. 6,163,780.

[0037]FIG. 7 is a flow diagram illustrating a third phase of a method ofconcentrating software in accordance with the invention described inU.S. Pat. No. 6,163,780.

[0038]FIG. 8 is a flow diagram illustrating a fourth phase of a methodof concentrating software in accordance with the invention described inU.S. Pat. No. 6,163,780.

[0039]FIG. 9 is a flow diagram illustrating a first portion of a fifthphase of a method of concentrating software in accordance with theinvention described in U.S. Pat. No. 6,163,780.

[0040]FIG. 10 is a flow diagram illustrating a second portion of a fifthphase of a method of concentrating software in accordance with theinvention described in U.S. Pat. No. 6,163,780.

[0041]FIG. 11 is a flow diagram illustrating a first phase of a methodof dynamically upgrading concentrated executable computer software codein accordance with the present invention.

[0042]FIG. 12 is a flow diagram illustrating a second phase of a methodof dynamically upgrading concentrated executable computer software codein accordance with the present invention.

[0043]FIG. 13 is a flow diagram illustrating a third phase of a methodof dynamically upgrading concentrated executable computer software codein accordance with the present invention.

[0044]FIG. 14 is a flow diagram illustrating a fourth phase of a methodof dynamically upgrading concentrated executable computer software codein accordance with the present invention.

[0045]FIG. 15 is a flow diagram illustrating a fifth phase of a methodof dynamically upgrading concentrated executable computer software codein accordance with the present invention.

[0046]FIG. 16 is a flow diagram illustrating a first part of a sixthphase of a method of dynamically upgrading concentrated executablecomputer software code in accordance with the present invention

[0047]FIG. 17 is a flow diagram illustrating a second part of a sixthphase of a method of dynamically upgrading concentrated executablecomputer software code in accordance with the present invention

[0048]FIG. 18 is a flow diagram illustrating a seventh phase of a methodof dynamically upgrading concentrated executable computer software codein accordance with the present invention

[0049]FIG. 19 is a flow diagram of an exemplary method of executingbytecode condensed in accordance with the present invention.

[0050]FIG. 20 is a flow diagram of an exemplary method of resolvingoperands of bytecode condensed in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0051] In accordance with the present invention, a system and method areprovided for dynamically upgrading concentrated executable computersoftware code. Such a system and method may be used in conjunction withvarious known computer languages and interpreters, including JAVA,various dialects of JAVA (such as the version available from MicrosoftCorporation), and other languages.

[0052] As shown in FIG. 1, the bytecode the subject of the upgrade(referred to hereafter as the “upgrade bytecode”) 74 may be storedwithin a server system 10, which is connected via an ECN 20 with usersystems 30. For example, the ECN 20 may include cable transmissionnetworks, telephone networks, an intranet, the Internet, or combinationsthereof. It will be understood that an ECN 20 as described herein mayinclude a single server computer, such as a single bulletin boardsystem.

[0053] As illustrated in FIG. 1, a plurality of server systems 10 may beconnected to the ECN 20 and a plurality of user systems 30 may also beconnected. The servers 10 may perform a number of functions includingstoring data and/or web page information and so on. In a preferredembodiment, at least one of the servers 10 has an associated memory 15which stores the upgrade bytecode 74 and which can transmit the upgradebytecode 74 via the ECN 20 to a user system 30. As utilised inconjunction with the present invention, the server memory 15 stores aconcentrated bytecode generated in accordance with the presentinvention. The server memory 15 may also store a concentrated bytecodegenerated in accordance with the invention disclosed by U.S. Pat. No.6,163,780 (as discussed below). The concentrated upgrade bytecode 74 maybe transmitted via the ECN 20 to a user system 30. Preferably, the usersystem 30 contains an API for integrating the concentrated upgradebytecode 74 with the concentrated original bytecode 72 and aninterpreter or other associated tool for receiving the integratedconcentrated bytecode 76 and executing it. The concentrated upgradebytecode 74 generated in accordance with the present invention may begenerated on a data processing system 40 as illustrated in FIG. 2.Typical data processing systems which may be used include personalcomputers, work stations, palm computers, personal digital assistants(PDAs) or even mainframe computers. Also, multiple systems coupled in acomputer network, with data files shared among systems on the network,may be employed. Data processing systems can be used to practice thepresent invention utilising a variety of operating systems (such as forexample, Windows™, Windows NT™, Windows 95™, Windows XP™, Sun OS™, OS/2™and Macintosh OS™) and programming languages.

[0054] As illustrated in FIG. 2 a typical data processing system 40includes a central processing unit (CPU) 50. The CPU 50 is optionallyconnected via a bus 60 to, among other things, a volatile memory 65 (eg.a RAM), non-volatile memory 70 (such as disk drives, CD-ROMs, flashmemory, or data tape), a network communications interface 75 (such as amodem, T1 line interface, ISDN modem or cable modem), a user inputdevice or devices 80 (such as keyboard and/or a pointing orpoint-and-click device such as a mouse, light pen, touch screen, touchpad), a user output device or devices 87 (such as a video display screenand/or an audio speaker), and a removable media drive 90 (such as afloppy disk drive, CD-ROM drive, PCMCIA device, CD-WORM drive or datatape drive). The data processing system 40 can be a personal computer(PC).

[0055] The data processing system 40 may be a free standing system,providing upgrade bytecode 74 concentrated in accordance with thepresent invention to a server 10 for transmission over the ECN 20.Alternatively, a server 10 may comprise the data processing system 40.Alternatively, the data processing system 40 may be in communicationwith user systems 30 via the ECN 20. In another embodiment, the dataprocessing system 40 may receive upgrade bytecode 74, concentrate iton-the-fly in accordance with the present invention and then transmit itas such to a server 10, or to another system via the ECN 20.

[0056] Although the method and system of the present invention can beused to great advantage within a networked system, as in the illustratedembodiment, it should be clear that the code concentrating method andsystem of the present invention can also be used to advantage innon-networked computer systems.

[0057] The upgrade bytecode 74 to be concentrated in accordance with thepresent invention can be stored in the RAM 65, the non-volatile memory70, or on the removable media 90. The upgrade bytecode to beconcentrated may also be transmitted on-the-fly to the data processingsystem 40, which in turn concentrates the upgrade bytecode on-the-flyand re-transmits the concentrated upgrade bytecode 74. In theillustrated embodiment, the upgrade bytecode 74 to be concentrated isstored in the non-volatile memory 70. In some applications, it may bedesirable to store the bytecode 72 in RAM for increased access speed.

[0058] The data processing system 40 also executes and preferably storesconcentrating software 95 for concentrating the upgrade bytecode 74 inaccordance with the present invention. The concentrating software 95 isillustrated in FIG. 2 as being stored in non-volatile memory 70.However, it should be understood that it can be stored in other wayssuch as in RAM 65 or on removable media inserted in the removable mediadrive 90.

[0059] Exemplary removable media for storing the concentrating software95 (which may be in any form, such as source code, compiled or binaryversions) are illustrated in FIGS. 3A, 3B and 3C as floppy disks,magnetic tape and optical disks, respectively. In the preferredembodiment, the concentrating software 95 is read into RAM 65 when it isto be executed. To concentrate the upgrade bytecode 74, theconcentrating software 95 is executed.

[0060] To provide a full understanding of the present invention, U.S.Pat. No. 6,163,780 is incorporated herein by reference. However, whilethe process described in that disclosure is almost identical to theprocess that forms part of the present invention, in the presentinvention the resulting canonical lists (referred to in thisspecification as “OriginalClassList”, “OriginalMethodList” and“OriginalFieldList” respectively) contain a field for recording theunique identifier of the item the subject of the canonical list and afield for identifying the offset of the class, method or field, asappropriate, from the start of the original bytecode 72 (the “OffsetField”). To illustrate, when the original bytecode 72 is loaded into RAM65 the first memory address taken up by the original bytecode 72 isrecorded. The value of the Offset Field for each entry in theOriginalClassList, OriginalMethodList and OriginalFieldList is thencalculated by determining the distance, in memory address terms, betweenthe first memory address taken up by the original bytecode 72 and thefirst memory address taken up by the bytecode that forms the basis ofthe class, method or field, as appropriate.

[0061] The process described in U.S. Pat. No. 6,63,780 is shownschematically in FIGS. 4 to 10.

[0062] Once concentrated, ideally, the OriginalClassList,OriginalMethodList and OriginalFieldList consists of abstract or minimalcanonical lists of classes, methods and fields. In this situation, theabstract or minimal lists are kept separate from the lists stored in avirtual table 92 (described in more detail below and first shown in FIG.18). In alternative arrangements, the OriginalClassList,OriginalMethodList and OriginalFieldList may be stored in their completeform as a record in the virtual table 92 or split such that the set ofabstract or minimal canonical lists of classes, methods and fields iskept separate from the virtual table 95 while the remainder is stored asa record in the virtual table 92. In either case the original bytecodeis adapted to refer to the abstract or minimal canonical list (if any)as well as the virtual table 92.

[0063] Once the original bytecode 72 has been processed in the mannerdescribed above, an upgrade can then be made without the need forreconcentration of the original bytecode 72 by adopting the followingprocess.

[0064] As shown in FIG. 11, the upgrade process commences with aninitialisation procedure 1000. The initialisation process 1000 consistsof a single step 1010 where three lists corresponding respectively toclasses, methods and fields are initialised to some default state, suchas empty. The lists in the illustrated embodiment are referred tohereafter as “UpgradeClassList”, “UpgradeMethodList” and“UpgradeFieldList”. Note that the lists are used as exemplary datastructures, but any suitable data structure may be used.

[0065] A pointer to the start of each list is then created andinitialised. These pointers will be referred to hereafter as“ClassListStart”, “MethodListStart” and “FieldListStart” as appropriate.At the same time, additional pointers to the end of each list arecreated and initialised. These pointers will be referred to hereafter as“ClassListEnd”, “MethodListEnd” and “FieldListEnd” as appropriate.

[0066] The process then continues to Phase 1 as indicated by step 1020.

[0067] In Phase 1, 1020 the upgrade bytecode 74 is scanned and theUpgradeClassList populated. This commences with step 1030, when theupgrade bytecode 74 is scanned for any class definitions or invocations.When a class definition or invocation is found, a check is made todetermine whether the class has already been recorded in theUpgradeClassList. If it is determined that the class has not alreadybeen recorded in the UpgradeClassList, the name of the class defined orinvoked is inserted, into the UpgradeClassList and ClassListEnd updatedto point to the newly inserted class. If it is determined that the classhas already been recorded in the UpgradeClassList, the scan for the nextclass definition or invocation continues.

[0068] In this manner, the UpgradeClassList ultimately generatedcontains the names of each of the classes that are defined or invokedwithin the upgrade bytecode 74 and ClassListEnd points to the last classinserted into the UpgradeClassList.

[0069] Any procedure for scanning the upgrade bytecode 74 may be used.

[0070] At step 1040, a first class is retrieved from theUpgradeClassList and a variable UC is filled with the name correspondingto that first class. In successive iterations of step 1040, variable UCis assigned the name of successive classes listed in theUpgradeClassList and each class is processed in accordance with thesteps that follow.

[0071] Variable UC thereby indicates the class that is currently beingprocessed, and such class is referred to herein as “Class UC”.

[0072] Upon reaching the end of the UpgradeClassList, the variable UC isassigned an “end-of-list” value (e.g., a null value) indicating thatthere are no more classes in the UpgradeClassList to be processed. If itis determined, at step 1050, that variable UC has been assigned a nullvalue, processing continues to the next phase, Phase 2, 1140. If UC hasnot been assigned a null value, thereby indicating that there are moreclasses to be processed, operation continues to step 1060.

[0073] At step 1060, Class UC is scanned to determine whether any otherclasses are defined or invoked therein. The distinction between a classdefinition and a class invocation is determined with reference to itscontext. To elaborate, a class definition will be prefaced by thereserved word or phrase necessary to define the class. In the JAVAprogramming language, for example, the reserved word used to indicatethat a new class has been defined is “class”.

[0074] Upon identification of a class definition or invocation, the nameof the class so defined or invoked is assigned to a variable UD.Further, if the identified class is a newly defined class, this fact isrecorded by setting boolean variable DefinedClass to true (this variableinitialised to false at first instance). If the scan of Class UC doesnot reveal any classes that are defined or invoked within Class UC,variable UD is assigned a null value.

[0075] In successive iterations of step 1060, variable UD is assignedthe name of the next class defined or invoked within Class UC, if any.If Class UC does not reference any further classes defined or invokedwithin the upgrade bytecode 74, variable UD is assigned a null value.

[0076] Processing then continues at step 1070 where the value assignedto variable UD is analysed. If variable UD has been assigned a nullvalue, processing returns to step 1040 where the next class identifiedin the UpgradeClassList is processed. If variable UD has been assignedany value other than a null value, processing moves to step 1080.

[0077] Step 1080 compares the value of variable UD, ie. the name of theclass defined or invoked in the upgrade bytecode 74, against the namesof classes already included in the UpgradeClassList. If this comparisondetermines that the class name, as recorded by variable UD, has alreadybeen included in the UpgradeClassList, processing continues to step1090. If the comparison determines that the class name, as recorded byvariable UD, has not already been included in the UpgradeClassList,processing continues to step 1110.

[0078] At step 1090, the value assigned to variable DefinedClass isanalysed. If variable DefinedClass has been assigned a true value,processing continues to step 1100. If variable DefinedClass has beenassigned a false value, processing returns to step 1060 where the nextclass identified in UpgradeClassList is processed.

[0079] Step 1100 commences by searching the UpgradeClassList for therecord corresponding to the class recorded by variable UD. Once found,the Offset Field value for this record is set by determining thedistance, in memory address terms, between the first memory addresstaken up by the upgrade bytecode 74 and the first memory address takenup by the bytecode that defines the class recorded by variable UD.Variable DefinedClass is then reset to a false value. Processing thenreturns to step 1060.

[0080] At step 1110, the class name, as recorded by variable UD, isadded to the UpgradeClassList at the position immediately after theclass pointed to by ClassListEnd. At step 1120, the value assigned tovariable DefinedClass is analysed. If variable DefinedClass has beenassigned a true value, processing continues to step 1130. If variableDefinedClass has been assigned a false value, processing returns to step1060 where the next class identified in UpgradeClassList is processed.

[0081] At step 1130, the Offset Field value for the class recorded byvariable UD is calculated. This is achieved by determining the distance,in memory address terms, between the first memory address taken up bythe upgrade bytecode 74 and the first memory address taken up by thebytecode that defines the class recorded by variable UD.

[0082] Processing then returns to step 1060.

[0083]FIG. 12 illustrates the steps involved in Phase 2, 1140. Phase 2,1140 involves scanning the upgrade bytecode 74 and populating theUpgradeMethodList with initially defined or identified methods. Thisphase commences with step 1150, where the upgrade bytecode 74 is scannedfor any method definitions or invocations.

[0084] When a method definition or invocation is found, a check is madeto determine whether the method has already been recorded in theUpgradeMethodList. If it is determined that the method has not alreadybeen recorded in the UpgradeMethodList, the name of the method definedor invoked is inserted, into the UpgradeMethodList, and MethodListEndupdated to point to the newly inserted method. If it is determined thatthe method has already been recorded in the UpgradeMethodList, the scanfor the next method definition or invocation continues.

[0085] In this manner, the UpgradeMethodList ultimately generatedcontains the names of each of the methods that are defined or invokedwithin the upgrade bytecode 74 and MethodListEnd points to the lastmethod inserted into the UpgradeMethodList.

[0086] Any procedure for scanning the upgrade bytecode 74 may be used.

[0087] Processing then continues at step 1160 where the UpgradeClassListis reset to its start, i.e., the class pointed to be ClassListStart. Thefirst class in the UpgradeClassList is then retrieved, at step 1170, andvariable UC assigned the name corresponding to that first class.

[0088] In successive iterations of step 1170, variable UC is assignedthe name of successive classes listed in the UpgradeClassList and eachclass is processed in accordance with the steps that follow. Variable UCthereby indicates the class that is currently being processed, and, asabove, such class is referred to as “Class UC”.

[0089] Upon reaching the end of the UpgradeClassList, the variable UC isassigned an “end-of-list” value (e.g., a null value) indicating thatthere are no more classes in the UpgradeClassList to be processed. If itis determined at step 1180, that variable UC has been assigned a nullvalue, processing continues to Phase 3, 1270. If UC has not beenassigned a null value, thereby indicating that there are more classes tobe processed, operation continues to step 1190.

[0090] In step 1190, Class UC is scanned to determine whether any othermethods are defined or invoked therein. The distinction between a methoddefinition and a method invocation is determined with reference to itscontext. To elaborate, a method definition will be prefaced by thereserved word or phrase necessary to define the method. In the JAVAprogramming language, for example, the reserved word used to indicatethat a new method has been defined is “method”.

[0091] Upon identification of a method definition or invocation, thename of the method so defined or invoked is assigned to a variable UM.Further, if the identified method is a newly defined method, this factis recorded by setting boolean variable DefinedMethod to true (thisvariable initialised to false at first instance). If the scan of ClassUC does not reveal any methods that are defined or invoked within ClassUC, variable UM is assigned a null value.

[0092] In successive iterations of step 1190, variable UM is assignedthe name of the next method defined or invoked within Class UC, if any.If Class UC does not reference any further methods defined or invokedwithin the upgrade bytecode 74, variable UM is assigned a null value.

[0093] Processing then continues at step 1200 where the value assignedto variable UM is analysed. If variable UM has been assigned a nullvalue, processing returns to step 1190 where the next class identifiedin the UpgradeClassList is processed. If variable UM has been assignedany value other than a null value, processing moves to step 1210.

[0094] Step 1210 compares the value of variable UM, ie. the name of themethod defined or invoked in the upgrade bytecode 74, against the namesof methods already included in the UpgradeMethodList. If this comparisondetermines that the method name, as recorded by variable UM, has alreadybeen included in the UpgradeMethodList, processing continues to step1220. If the comparison determines that the method name, as recorded byvariable UM, has not already been included in the UpgradeMethodList,processing continues to step 1240.

[0095] At step 1220, the value assigned to variable DefinedMethod isanalysed. If variable DefinedMethod has been assigned a true value,processing continues to step 1230. If variable DefinedMethod has beenassigned a false value, processing returns to step 1190 where the nextclass identified in UpgradeClassList is processed.

[0096] Step 1230 commences by searching the UpgradeMethodList for therecord corresponding to the method recorded by variable UM. Once found,the Offset Field value for this record is set by determining thedistance, in memory address terms, between the first memory addresstaken up by the upgrade bytecode 74 and the first memory address takenup by the bytecode that defines the method recorded by variable UM.

[0097] Variable DefinedMethod is then reset to a false value. Processingthen returns to step 1190.

[0098] At step 1240, the method name, as recorded by variable UM, isadded to the UpgradeMethodList at the position immediately after themethod pointed to by MethodListEnd. At step 1250, the value assigned tovariable DefinedMethod is analysed.

[0099] If variable DefinedMethod has been assigned a true value,processing continues to step 1260. If variable DefinedMethod has beenassigned a false value, processing returns to step 1190 where the nextclass identified in UpgradeClassList is processed.

[0100] At step 1260, the Offset Field value for the method recorded byvariable UM is calculated. This is achieved by determining the distance,in memory address terms, between the first memory address taken up bythe upgrade bytecode 74 and the first memory address taken up by thebytecode that defines the method recorded by variable UM.

[0101] Processing then returns to step 1190.

[0102] Once all method definitions have been found, as indicated byvariable UC having been assigned a null value when analysed at step1170, processing continues to Phase 3, 1270, to facilitate population ofthe UpgradeFieldList.

[0103]FIG. 13. Illustrates the steps involved in Phase 3, 1270. Phase 3,1270, involves scanning the upgrade bytecode 74 and populating theUpgradeFieldList with initially identified fields (typically publicfields). This phase commences with step 1280, where the upgrade bytecode74 is scanned for any reserved words indicating that a new field hasbeen defined or referenced.

[0104] As described above, any series of processing steps to scan theupgrade bytecode 74 may be employed.

[0105] The name of the newly defined field is then inserted into theUpgradeFieldList at the position immediately after the field pointed tobe FieldListEnd and FieldListEnd updated to point to the newly insertedfield. In this manner, the UpgradeFieldList ultimately generatedcontains the name of each of the fields that are defined or referencedwithin the upgrade bytecode 74. Processing then continues at step 1290.

[0106] At step 1290, UpgradeClassList is reset to its start, i.e., theclass pointed to be ClassListStart. The first class in theUpgradeClassList is then retrieved, at step 1300, and variable UCassigned the name corresponding to that first class.

[0107] In successive iterations of step 1300, variable UC is assignedthe name of successive classes listed in the UpgradeClassList and eachclass is processed in accordance with the steps that follow. Variable UCthereby indicates the class that is currently being processed, and, asabove, such class is referred to as “Class UC”.

[0108] Upon reaching the end of the UpgradeClassList, the variable UC isassigned an “end-of-list” value (e.g., a null value) indicating thatthere are no more classes in the UpgradeClassList to be processed. If itis determined at step 1310, that variable UC has been assigned a nullvalue, processing continues to Phase 4, 1510. If UC has been assignedany value other than a null value, thereby indicating that there aremore classes to be processed, operation continues to step 1320.

[0109] In step 1320, Class UC is scanned to determine whether any otherfields are defined or referenced therein. The distinction between afield definition and a field reference is determined with reference toits context. To elaborate, a field definition will be prefaced by thereserved word or phrase necessary to define the field. Such reservewords or phrases may vary according to the programming language of theupgrade bytecode 74.

[0110] Upon identification of a field definition or reference, the nameof the field so defined or referenced is assigned to a variable UF.Further, if the identified field is a newly defined, this fact isrecorded by setting boolean variable DefinedField to true (this variableinitialised to false at first instance). If the scan of Class UC doesnot reveal any fields that are defined or referenced within Class UC,variable UF is assigned a null value.

[0111] In successive iterations of step 1320, variable UF is assignedthe name of the next field defined or referenced within Class UC, ifany. If Class UC does not reference any further fields defined orreferenced within the upgrade bytecode 74, variable UF is assigned anull value.

[0112] Processing then continues at step 1330 where the value assignedto variable UF is analysed. If variable UF has been assigned a nullvalue, processing continues at step 1400. If variable UF has beenassigned any value other than a null value, processing moves to step1340.

[0113] Step 1340 compares the value of variable UF, i.e., the name ofthe field defined or referenced in the upgrade bytecode 74, against thenames of fields already included in the UpgradeFieldList. If thiscomparison determines that the field name, as recorded by variable UF,has already been included in the UpgradeFieldList, processing continuesto step 1350. If the comparison determines that the field name, asrecorded by variable UF, has not already been included in theUpgradeFieldList, processing continues to step 1370.

[0114] At step 1350, the value assigned to variable DefinedField isanalysed. If variable DefinedField has been assigned a true value,processing continues to step 1360. If variable DefinedField has beenassigned a false value, processing returns to step 1320 where the nextfield identified in UpgradeFieldList is processed.

[0115] Step 1360 commences by searching the UpgradeFieldList for therecord corresponding to the field recorded by variable UF. Once found,the Offset Field value for this field is set by determining thedistance, in memory address terms, between the first memory addresstaken up by the upgrade bytecode 74 and the first memory address takenup by the bytecode that defines the field recorded by variable UF.Variable DefinedField is then reset to a false value. Processing thenreturns to step 1320.

[0116] At step 1370, the field name, as recorded by variable UF, isadded to the UpgradeFieldList at the position immediately after thefield pointed to by FieldListEnd. At step 1380, the value assigned tovariable DefinedField is analysed. If variable DefinedField has beenassigned a true value, processing continues to step 1390. If variableDefinedField has been assigned a false value, processing returns to step1320 where the next class identified in UpgradeClassList is processed.

[0117] At step 1390, the Offset Field value for the field recorded byvariable UF is calculated. This is achieved by determining the distance,in memory address terms, between the first memory address taken up bythe upgrade bytecode 74 and the first memory address taken up by thebytecode that defines the field recorded by variable UF.

[0118] Processing then returns to step 1320.

[0119] This process repeats until all fields defined or referenced inClass UC have been identified.

[0120] At step 1400, Class UC is rest to its start. A scan is thencommenced, at step 1410, of Class UC for any method invocations. When amethod invocation is found, the name of the method invoked is assignedto variable UM. If Class UC does not include any method invocations,variable UM is assigned an “end-of-list” value, such as a null value.

[0121] In successive iterations of step 1410, variable UM is assignedthe name of successive method invocations in Class UC and each method isprocessed in accordance with the steps that follow. Variable UM therebyindicates the method that is currently being processed, and such methodwill be referred to herein as “Method UM”.

[0122] At step 1420, the value of variable UM is analysed to determinewhether it has been assigned a null value. If variable UM has beenassigned a null value, processing returns to step 1300 where the nextclass in the UpgradeClassList is processed. If variable UM has beenassigned any value other than a null value, processing continues to step1430.

[0123] At step 1430, method UM is scanned to determine the next definedor referenced field. The first of any such fields referenced is assignedto a variable UF. If the scan of Method UM does not reveal any fieldreferences, or any further field references, variable UF is assigned anull value.

[0124] In successive iterations of step 1430, variable UF is assignedthe name of the next field defined or referenced within Method UM. IfMethod UM does not refer to any further fields, variable UF is assigneda null value.

[0125] Processing then continues at step 1440 where the value ofvariable UF is analysed. If variable UF is assigned a null value,processing continues at step 1430 where the next method defined orreferenced in Class UC is identified. If variable UF is assigned anyvalue other than a null value, processing moves to step 1450.

[0126] Step 1450 compares the value of variable UF, ie. the name of thefield defined or referenced in the upgrade bytecode 74, against thenames of fields already included in the UpgradeFieldList. If thiscomparison determines that the field name, as recorded by variable UF,has already been included in the UpgradeFieldList, processing continuesto step 1460. If the comparison determines that the field name, asrecorded by variable UF, has not already been included in theUpgradeFieldList, processing continues to step 1480.

[0127] At step 1460, the value assigned to variable DefinedField isanalysed. If variable DefinedField has been assigned a true value,processing continues to step 1480. If variable DefinedField has beenassigned a false value, processing returns to step 1430 where the nextmethod identified in UpgradeMethodList is processed.

[0128] Step 1470 commences by searching the UpgradeFieldList for therecord corresponding to the field recorded by variable UF. Once found,the Offset Field value for this field is set by determining thedistance, in memory address terms, between the first memory addresstaken up by the upgrade bytecode 74 and the first memory address takenup by the bytecode that defines the field recorded by variable UF.Variable DefinedField is then reset to a false value. Processing thenreturns to step 1430.

[0129] At step 1480, the field name, as recorded by variable UF, isadded to the UpgradeFieldList at the position immediately after thefield pointed to by FieldListEnd. At step 1490, the value assigned tovariable DefinedField is analysed. If variable DefinedField has beenassigned a true value, processing continues to step 1500. If variableDefinedField has been assigned a false value, processing returns to step1430 where the next method identified in UpgradeMethodList is processed.

[0130] At step 1500, the Offset Field value for the field recorded byvariable UF is calculated. This is achieved by determining the distance,in memory address terms, between the first memory address taken up bythe upgrade bytecode 74 and the first memory address taken up by thebytecode that defines the field recorded by variable UF.

[0131] Processing then returns to step 1430.

[0132] This process repeats until all methods invoked in Class UC havebeen traversed to identify any field referenced and all field referencesin each such method, i.e., Method UM, have been identified andprocessed.

[0133]FIG. 14 shows the steps that form Phase 4, 1510. Phase 4,commences by sorting the UpgradeClassList to create a canonical form, asillustrated by step 1520. Steps 1530 and 1540 are then processed to sortthe UpgradeMethodList and UpgradeFieldList, respectively, to createcanonical forms of each. Processing then proceeds to Phase 5, 1550 (seeFIG. 15).

[0134] Phase 5, 1550 commences at step 1560 by resettingUpgradeClassList such that reference is made to the first class includedtherein, i.e., to the class pointed to by ClassListStart. The firstclass in the UpgradeClassList is then retrieved, at step 1570, and thevariable UC filled with the name corresponding to that first class.

[0135] In successive iterations of step 1570, variable UC is assignedthe name of successive classes listed in the UpgradeClassList and eachclass is processed in accordance with the steps that follow. Variable UCthereby indicates the class that is currently being processed, and, asabove, such class will be referred to as “Class UC”. Upon reaching theend of the UpgradeClassList, the variable UC is assigned an“end-of-list” value (e.g., a null value) indicating that there are nomore classes in the UpgradeClassList to be processed. If it isdetermined, at step 1580, that variable UC has been assigned a nullvalue, processing continues to Phase 6, 1680. If UC has been assignedany value other than a null value, thereby indicating that there aremore classes to be processed, operation continues to step 1590.

[0136] Step 1590 comprises two actions. Firstly, an array of localconstant data for Class UC is created. Secondly, the array isinitialised to some default state such as empty. Subsequent iterationsof step 1590 see a new array of local constant data being created andinitialised, each new array being associated with the class then beingprocessed, i.e., Class UC.

[0137] Processing then continues to step 1600. At step 1600, Class UC isscanned for a reference to a local constant data. When, and if, so foundthe name of the local constant data so referenced is assigned tovariable UV. If Class UC contains no references to local constant data,variable UV is assigned a null value.

[0138] In successive iterations of step 1600, variable UV is assignedthe name of the next local constant data referenced within Class UC. IfClass UC does not refer to any further local constant data, variable UVis assigned a null value.

[0139] Step 1610 involves the analysis of the value assigned to variableUV. If variable UV has been assigned a null value processing continuesat step 1610. If variable UV has been assigned any value other than anull value, processing continues to step 1620.

[0140] At step 1610, the value assigned to variable UV is saved in thearray of local constant data created at step 1590. The reference inClass UC to the local constant data is then replaced with the valuerepresenting the position in the array of local constant data where thevalue assigned to variable UV has been saved. Processing then returns tostep 1590.

[0141] Once all local constant data references in Class UC have beenidentified and saved in the array of local constant data, processingmoves to step 1620.

[0142] At step 1620, Class UC is again reset to its start. A scan isthen commenced, at step 1630, of Class UC for any method invocations.When a method invocation is found, the name of the method invoked isassigned to variable UM. If Class UC does not include any methodinvocations, variable UM is assigned an “end-of-list” value, such as anull value.

[0143] In successive iterations of step 1630, variable UM is assignedthe name of successive method invocations in Class UC and each method isprocessed in accordance with the steps that follow. Variable UM therebyindicates the method that is currently being processed, and, asdiscussed above, such methods will be referred to as “Method UM”.

[0144] At step 1640, the value of variable UM is analysed to determinewhether it has been assigned a null value. If variable UM has beenassigned a null value, processing returns to step 1570 where the nextclass in the UpgradeClassList is processed. If variable UM has beenassigned any value other than a null value processing continues to step1650.

[0145] Step 1650 sees method UM scanned to determine the next localconstant data reference. The first of any such references is assigned toa variable UV. If the scan of Method UM does not reveal any localconstant data references, or any further local constant data references,variable UV is assigned a null value.

[0146] In successive iterations of step 1650, variable UV is assignedthe name of the next local constant data referenced within Method UM. IfMethod UM does not refer to any further local constant data, variable UVis assigned a null value.

[0147] Processing then continues at step 1660 where the value ofvariable UV is analysed. If variable UV is assigned a null value,processing returns to step 1630 where the next method invoked in ClassUC is identified. If variable UV is assigned any value other than a nullvalue, processing moves to step 1670.

[0148] At step 1670, the value assigned to variable UV is saved in thearray of local constant data created at step 1580. The reference inClass UC to the local constant data where the value assigned to variableUV has been saved. Processing then returns to step 1650.

[0149] This process repeats until all methods invoked in Class UC havebeen traversed to identify any local constant data references and alllocal constant data references in each such method, i.e., Method UM,have been identified and saved in the array of local constant data forClass UC.

[0150] Phase 6, 1680, sees the classes, methods and fields defined andreferenced in the upgrade bytecode 74 replaced with a reference to theappropriate entry in the appropriate canonical list. The phase commenceswith step 1690 and is illustrated in FIGS. 16 to 18.

[0151] Step 1690 commences by assigning the size, in memory addressterms, of the concentrated original bytecode 72 to a variableOriginalBytecodeSize. Thereafter, the size, in memory terms, of theunconcentrated upgrade bytecode 74 is assigned to a variableUpgradeBytecodeSize. Processing then continues at step 1700.

[0152] At step 1700 a linear scan of the upgrade bytecode 74 commencesfor classes, methods and fields. The first identified reference to aclass, method or field is assigned to a variable CMF. Processing thencontinues at step 1710.

[0153] At step 1710, the value of variable CMF is analysed to determinewhether the reference is to a class. If CMF does reference a class,processing continues to step 1720. Otherwise, processing continues tostep 1750.

[0154] Step 1720 compares the value of variable CMF, ie. the name of theclass, against the names of classes already included in theUpgradeClassList. If the comparison determines that the class name, asrecorded by variable CMF, has been included in the UpgradeClassList,processing continues to step 1730. If the comparison determines that theclass name, as recorded by variable CMF, has not been included in theUpgradeClassList, an error is raised and appropriate error-handlingprocedures invoked at step 1740.

[0155] At step 1730, the reference to the class name replaced with theindex value of the corresponding class name in UpgradeClassList. Forexample, if the class name corresponded with the fifth entry in theUpgradeClassList, the reference to the class name would be replaced bythe number 5. Processing then continues at step 1840.

[0156] The value of variable CMF is further analysed, at step 1750, todetermine whether the reference is to a method. If CMF does reference amethod, processing continues to step 1760. Otherwise processingcontinues to step 1790.

[0157] Step 1760 compares the value of variable CMF, i.e., the name ofthe method, against the names of methods already included in theUpgradeMethodList. If the comparison determines that the method name, asrecorded by variable CMF, has been included in the UpgradeMethodList,processing continues to step 1770. If the comparison determines that themethod name, as recorded by variable CMF, has not been included in theUpgradeMethodList, an error is raised and appropriate error-handlingprocedures invoked at step 1780.

[0158] At step 1770, the reference to the method name is replaced withthe index value of the corresponding method name in UpgradeMethodList inthe same manner as a class reference is replaced at step 1730.Processing then continues at step 1840.

[0159] Again, the value of variable CMF is analysed, at step 1790, todetermine whether the reference is to a field. If CMF does reference afield, processing continues to step 1800. Otherwise, an error is raisedand appropriate error-handling procedures invoked at step 1830.

[0160] Step 1800 compares the value of variable CMF, i.e., the name ofthe field, against the names of fields already included in theUpgradeFieldList. If the comparison determines that the field name, asrecorded by variable CMF, has been included in the UpgradeFieldList,processing continues to step 1810. If the comparison determines that thefield name, as recorded by variable CMF, has not been included in theUpgradeFieldList, an error is raised and appropriate error-handlingprocedures invoked at step 1820.

[0161] At step 1810, the reference to the field name is replaced withthe index value of the corresponding field name in UpgradeFieldList inthe same manner as a class reference is replaced at step 1730.Processing then continues at step 1840.

[0162] It should be noted that replacing class names, method names andfield names with index values will affect the size of the upgradebytecode 74. With the exception of the Offset Field for the first entryas processed at steps 1700 to 1830 above, this results in the OffsetField values for each defined class/method/field entry in theirrespective canonical list (i.e., UpgradeClassList, UpgradeMethodList andUpgradeFieldList) pointing to a memory address that does not correspondwith the first memory address taken up by the definedclass/method/field. Thus, there needs to be a means of correcting thiserror.

[0163] At step 1840 the linear scan of the upgrade bytecode 74 continuesfor further classes, methods and fields. When found, the class, methodor field reference is assigned to the variable CMF. If the linear scandoes not identify, at step 1845, any further classes, methods or fieldsin the upgrade bytecode 74, processing continues to Phase 7, 2040.Otherwise processing continues to step 1850.

[0164] At step 1850, the value of variable CMF is analysed to determinewhether the reference is to a class. If CMF does reference a class,processing continues to step 1860. Otherwise, processing continues tostep 1910.

[0165] Step 1860 compares the value of variable CMF, i.e., the name ofthe class, against the names of classes already included in theUpgradeClassList. If the comparison determines that the class name, asrecorded by variable CMF, has been included in the UpgradeClassList,processing continues to step 1870. If the comparison determines that theclass name, as recorded by variable CMF, has not been included in theUpgradeClassList, an error is raised and appropriate error-handlingprocedures invoked at step 1880.

[0166] At step 1870, the reference to the class name is replaced withthe index value of the corresponding class name in UpgradeClassList.Thereafter, at step 1890, the Offset Field value for the class name isanalysed. If the Offset Field value is set to its initialised value(such as a null value), processing returns to step 1840 where the linearscan resumes and the next class, method or field reference is processed.

[0167] If the Offset Field value is set to any value other than itsinitialised value, the Offset Field value is corrected at step 1900.This correction is achieved by determining the then current size, inmemory address terms, of the upgrade bytecode 74 and subtracting fromthat value the value recorded by UpgradeBytecodeSize. This results in a“difference” value that is the result of previous replacements. TheOffset Field value then being processed is then “corrected” by addingthis “difference” value to the current value of the Offset Field.

[0168] Additionally, the value recorded by OriginalBytecodeSize is addedto the current value of the Offset Field (incorporating the “differencevalue”). The reason for this is explained in more detail below.

[0169] Processing then returns to step 1840.

[0170] The value of variable CMF is further analysed, at step 1910, todetermine whether the reference is to a method. If CMF does reference amethod, processing continues to step 1920. Otherwise processingcontinues to step 1970.

[0171] Step 1920 compares the value of variable CMF, ie. the name of themethod, against the names of methods already included in theUpgradeMethodList. If the comparison determines that the method name, asrecorded by variable CMF, has been included in the UpgradeMethodList,processing continues to step 1930. If the comparison determines that themethod name, as recorded by variable CMF, has not been included in theUpgradeMethodList, an error is raised and appropriate error-handlingprocedures invoked at step 1940.

[0172] At step 1930, the reference to the method name is replaced withthe index value of the corresponding method name in UpgradeMethodList.Thereafter, at step 1950, the Offset Field value for the method name isanalysed. If the Offset Field value is set to its initialised value(such as a mill value), processing returns to step 1840 where the linearscan resumes and the next class, method or field reference is processed.

[0173] If the Offset Field value is set to any value other than itsinitialised value, the Offset Field value is corrected at step 1960.This correction is achieved by determining the then current size, inmemory address terms, of the upgrade bytecode 74 and subtracting fromthat value the value recorded by UpgradeBytecodeSize. This results in a“difference” value that is the result of previous replacements. TheOffset Field value then being processed is then “corrected” by addingthis “difference” value to the current value of the Offset Field.

[0174] Additionally, the value recorded by OriginalBytecodeSize is addedto the current value of the Offset Field (incorporating the “differencevalue”). Again, the reason for this is explained in more detail below.

[0175] Processing then returns to step 1840.

[0176] Again, the value of variable CMG is analysed, at step 1970, todetermine whether the reference is to a field. If CMF does reference afield, processing continues to step 1980. Otherwise, an error is raisedand appropriate error-handling procedures invoked at step 1990.

[0177] Step 1980 compares the value of variable CMF, i.e., the name ofthe field, against the names of fields already included in theUpgradeFieldList. If the comparison determines that the field name, asrecorded by variable CMF, has been included in the UpgradeFieldList,processing continues to step 2000. If the comparison determines that thefield name, as recorded by variable CMF, has not been included in theUpgradeFieldList, an error is raised and appropriate error-handlingprocedures invoked at step 2010.

[0178] At step 2000, the reference to the field name is replaced withthe index value of the corresponding method name in UpgradeMethodList.Thereafter, at step 2020, the Offset Field value for the method name isanalysed. If the Offset Field value is set to its initialised value(such as a null value), processing returns to step 1840 where the linearscan resumes and the next class, method or field reference is processed.

[0179] If the Offset Field value is set to any value other than itsinitialised value, the Offset Field value is corrected at step 2030.This correction is achieved by determining the then current size, inmemory address terms, of the upgrade bytecode 74 and subtracting fromthat value the value recorded by UpgradeBytecodeSize. This results in a“difference” value that is the result of previous replacements. TheOffset Field value then being processed is then “corrected” by addingthis “difference” value to the current value of the Offset Field.

[0180] Additionally, the value recorded by OriginalBytecodeSize is addedto the current value of the Offset Field (incorporating the “differencevalue”).

[0181] Processing then returns to step 1840.

[0182] Phase 7, 2040, commences with step 2050 (see FIG. 18). Step 2050inserts the UpgradeClassList, the UpgradeMethodList and theUpgradeFieldList, as well as the local constant data arrays, in tovirtual table 92. Virtual table 92, comprises a series of records. Inaddition to fields for storing canonical class lists, canonical methodlists, canonical field lists and local constant data arrays, each recordcontains a unique identifier. In the embodiment presently beingdescribed, the unique identifier for each record is the size of theconcentrated original bytecode, ie. the value of OriginalBytecodeSize.Records within the virtual table 92 are sorted, in ascending order,according to the value of the unique identifier.

[0183] Processing then continues to step 2060 where the UpgradeClassListof the newly inserted record is reset to its initial entry, ie. theentry pointed to by ClassListStart. The first class, ie. the classpointed to by ClassListStart, is then assigned, at step 2070, to avariable UC and the class recorded by variable UC will be referred to as“Class UC”. In successive iterations of step 2070, variable UC isassigned the name of the next class in the UpgradeClassList of the newlyinserted record. Upon reaching the end of the UpgradeClassList, i.e.,the class pointed to by ClassListEnd has previously been processed,variable UC is assigned an “end-of-list” value (i.e., a null value).

[0184] At step 2080, Class UC is analysed. If Class UC has been assigneda null value, processing continues to step 2130. Otherwise, processingcontinues to step 2090.

[0185] At step 2090, Class UC is compared against the classes containedin the OriginalClassList (more particularly, the canonical class list ofthe record stored in the virtual table 92 that corresponds with theOriginalClassList). If a corresponding entry to Class UC is found in theOriginalClassList, processing continues to step 2100. Otherwiseprocessing returns to step 2070 where the next class in theUpgradeClassList is processed.

[0186] The Offset Field value of Class UC is analysed, at step 2100, todetermine whether this value is set to its initialised value. If so, theOffset Field value of Class UC is set, at step 2110, to equal the OffsetField value of the class corresponding to Class UC in theOriginalClassList. If the Offset Field value of Class UC is set to avalue other than its initialised value, then, at step 2120, the OffsetField value of the class corresponding to Class UC in theOriginalClassList is set to equal the Offset Field value of Class UC.

[0187] The former arrangement thus allows the UpgradeClassList tocorrectly reference classes defined in the OriginalClassList, while thelatter arrangement allows for dynamic upgrading of existing classes bypointing the original entry to the start of the bytecode that forms theupgraded class.

[0188] Processing then returns to step 2070 where the next class in theUpgradeClassList is processed.

[0189] At step 2130 the UpgradeMethodList of the newly inserted recordis reset to its initial entry, i.e., the entry pointed to byMethodListStart. The first method, ie. the method pointed to byMethodListStart, is then assigned, at step 2140, to a variable UM andthe method recorded by variable UM will be referred to as “Method UC”.

[0190] In successive iterations of step 2140, variable UM is assignedthe name of the next method in the UpgradeMethodList of the newlyinserted record. Upon reaching the end of the UpgradeMethodList, i.e.,the method pointed to by MethodListEnd has previously been processed,variable UM is assigned an “end-of-list” value (i.e., a null value).

[0191] At step 2150, Method UM is analysed. If Method UM has beenassigned a null value, processing continues to step 2200. Otherwise,processing continues to step 2160.

[0192] At step 2160, Method UM is compared against the methods containedin the OriginalMethodList (more particularly, the canonical method listof the record stored in the virtual table 92 that corresponds with theOriginalMethodList). If a corresponding entry to Method UM is found inthe OriginalMethodList, processing continues to step 2170. Otherwiseprocessing returns to step 2140 where the next method in theUpgradeMethodList is processed.

[0193] The Offset Field value of Method UM is analysed, at step 2170, todetermine whether this value is set to its initialised value. If so, theOffset Field value of Method UM is set, at step 2180, to equal theOffset Field value of the method corresponding to Method UM in theOriginalMethodList. If the Offset Field value of Method UM is set to avalue other than its initialised value, then, at step 2190, the OffsetField value of the method corresponding to Method UM in theOriginalMethodList is set to equal the Offset Field value of Method UM.

[0194] The former arrangement thus allows the UpgradeMethodList tocorrectly reference methods defined in the OriginalMethodList, while thelatter arrangement allows for dynamic upgrading of existing methods bypointing the original entry to the start of the bytecode that forms theupgraded method.

[0195] Processing then returns to step 2140 where the next method in theUpgradeMethodList is processed.

[0196] Step 2200 sees the UpgradeFieldList of the newly inserted recordreset to its initial entry, i.e., the entry pointed to byFieldListStart. The first field, i.e., the field pointed to byFieldListStart, is then assigned, at step 2210, to a variable UF and thefield recorded by variable UF will be referred to as “Field UF”.

[0197] In successive iterations of step 2210, variable UF is assignedthe name of the next field in the UpgradeFieldList of the newly insertedrecord. Upon reaching the end of the UpgradeFieldList, i.e., the fieldpointed to by FieldListEnd has previously been processed, variable UF isassigned an “end-of-list” value (i.e., a null value).

[0198] At step 2220, Field UF is analysed. If Field UF has been assigneda null value, processing continues to step 2270. Otherwise, processingcontinues to step 2230.

[0199] At step 2230, Field UF is compared against the fields containedin the OriginalFieldList (more particularly, the canonical field list ofthe record stored in the virtual table 92 that corresponds with theOriginalFieldList). If a corresponding entry to Field UF is found in theOriginalFieldList, processing continues to step 2240. Otherwiseprocessing returns to step 2210 where the next field in theUpgradeFieldList is processed.

[0200] The Offset Field value of Field UF is analysed, at step 2240, todetermine whether this value is set to its initialised value. If so, theOffset Field value of Field UF is set, at step 2250, to equal the OffsetField value of the field corresponding to Field UF in theOriginalFieldList. If the Offset Field value of Field UF is set to avalue other than its initialised value, then, at step 2260, the OffsetField value of the field corresponding to Field UF in theOriginalFieldList is set to equal the Offset Field value of Field UF.

[0201] The former arrangement then allows the UpgradeFieldList tocorrectly reference fields defined in the OriginalFieldList, while thelatter arrangement allows for dynamic upgrading of existing fields bypointing the original entry to the start of the bytecode that referencesthe upgraded field.

[0202] Processing then returns to step 2210 where the next class in theUpgradeClassList is processed.

[0203] At step 2270, the upgrade bytecode 74 is appended to the originalbytecode 72 to form an integrated bytecode 76. Once integrated, theupgrade process is completed, as illustrated at step 2280.

[0204] It should be noted that steps 2040 to 2260 is performed at thesite of the virtual table, which may be the location of the dataprocessing system 40 containing the original bytecode or some otherremote system. Furthermore, in alternative embodiments, the actions thatform step 2050 can be delayed and performed in conjunction with step2270.

[0205] Execution of the integrated bytecode 76 will now be describedwith reference to FIGS. 19 and 20.

[0206] At step 2280, the memory address of the first instruction in theintegrated bytecode is assigned to variable MemoryAddressStart.Thereafter, at step 2290, the first record in the virtual table isdesignated the “operative” record. The canonical list of classes,methods and fields of the operative record form the “ClassList”,“MethodList” and “FieldList” referred to below. Similarly, the localconstant data arrays associated with the canonical list of classes ofthe operative record forms the local constant data array.

[0207] Processing then continues as follows.

[0208] Each instruction in the integrated bytecode 76 consists of anopcode specifying the operation to be performed, followed by zero ormore operands supplying arguments or data to be used by the operation.As shown in FIG. 20, the first step in the execution of an instructionis to fetch the opcode, step 2310. At step 2320, it is determinedwhether the opcode fetched has any operands associated with it. If not,operation branches forward to step 2330 in which the operation specifiedby the opcode is executed.

[0209] If there are operands, operation proceeds to step 2340 in whichthe operands are fetched from the bytecode. Operation then proceeds tostep 2350 in which it is determined whether any of the fetched operandsneeds to be resolved. Generally, an operand will need to be resolved ifit is not a literal constant. Opcodes that refer to classes, methods offields have operands that need to be resolved. The type of operand isimplied by the opcode. For example, the “putfield” operation take avalue of the stack and moves it into the field of an object. The operandwhich immediately follows the “putfield” operator in the bytecode is afield identifier which specifies the field. In bytecode concentrated inaccordance with the present invention, the operand will be an index intothe FieldList.

[0210] If no operand needs to be resolved, operation proceeds to step2330 in which the operation specified by the opcode is executed usingthe operands. If there are operands to be resolved, operation proceedsto step 2360 in which the operands are resolved. This procedure will bedescribed in greater detail below with reference to FIG. 20. Once theoperands have been resolved, operation continues to step 2330 in whichthe operation specified by the opcode is carried out with the resolvedoperands. Thereafter, at step 2370, the next opcode to be processed isdetermined with reference to the Offset Field values of the operands.

[0211] Once the current instruction is executed, it is determined instep 2380 whether there are more instructions in the integrated bytecode76 to be executed. If there are, operation loops back to step 2310 inwhich the next opcode to be executed is fetched. If there are no moreinstructions to be executed, operation terminates at step 2390.

[0212]FIG. 20 illustrates an exemplary procedure for resolving operandsin accordance with the present invention. In step 2400, the memoryaddress of the opcode, to which the operand then being processedrelates, is assigned to a variable CurrentMemoryAddress.

[0213] The value of CurrentMemoryAddress is then adjusted by subtractingthe value of MemoryAddressStart to determine the relative offset valueof the opcode.

[0214] The value of CurrentMemoryAddress is then analysed at step 2410.If the value of CurrentMemoryAddress is greater than the value of theunique identifier for any record in the virtual table 92, other than theunique identifier for the current operative record, processing continuesto step 2420. Otherwise, processing continues at step 2430.

[0215] At step 2420, a new record is designated as the operative record.The new operative record is the record having a unique identifier valueclosest to, but not exceeding, the value of CurrentMemoryAddress. Onceidentified, the ClassList, MethodList and FieldList are changed toreflect those recorded in the new operative record. Processing thencontinues to step 2430.

[0216] Step 2430 sees the operand to be resolved assigned to a variableN. In step 2440, it is determined whether the operand is a class. Asdiscussed above, the type of operand is implied from the opcode. If theoperand N is a class, operation proceeds to step 2450 in which theoperand itself is used as an index into the ClassList.

[0217] At step 2450, and using the operand as an index to the ClassList,a string is retrieved from the ClassList which is the identifier of theclass which is the operand. The retrieved string replaces the index, andoperation either proceeds to step 2330 if all operands that need to beresolved have been resolved, or to step 2430 if there are more operandsto be resolved.

[0218] If at step 2440 it is determined that the operand N is not aclass, operation proceeds to step 2460 in which it is determined whetherthe operand to be resolved is a field. If it is determined that theoperand N is a field, operation proceeds to step 2470 in which theoperand itself is used as an index into the FieldList.

[0219] At step 2470, and using the operand as an index to the FieldList,a string is retrieved from the FieldList which is the identifier of thefield which is the operand. The retrieved string replaces the index, andoperation either proceeds to step 2330 is all operands that need to beresolved have been resolved, or to step 2430 if there are more operandsto be resolved.

[0220] If at step 2460 it is determined that the operand N is not afield, operation proceeds to step 2480 in which it is determined whetherthe operand to be resolved is a method. If it is determined that theoperand N is a method, operation proceeds to step 2490 in which theoperand itself is used as an index into the MethodList.

[0221] At step 2490, and using the operand as an index to theMethodList, a string is retrieved from the MethodList which is theidentifier of the method which is the operand.

[0222] The retrieved string replaces the index, and operation eitherproceeds to step 2330 is all operands that need to be resolved have beenresolved, or to step 2430 if there are more operands to be resolved.

[0223] If at step 2480 it is determined that the operand is not amethod, an error is raised and appropriate error-handling proceduresinvoked at step 2500.

[0224] It is possible to use the invention described herein for multipleupgrades of the original bytecode 72. When doing so the integratedbytecode 76 formed from previous upgrades constitutes the originalbytecode 72. The unique identifier for each record created by suchupgrade is then allocated a value equal to the total size, in memoryaddress terms, of the original bytecode 72 and the subsequent appendedupgrade bytecode(s) 74.

[0225] One skilled in the art will appreciate that the present inventioncan be practiced by other than the preferred embodiments which arepresented herein for purposes of illustration and not of limitation.

We claim:
 1. A method of dynamically upgrading a concentrated executablecomputer code in a computer system, the concentrated code including: a.a plurality of types of code structures, each of the types of codestructures having a plurality of code identifiers; b. a first list of aplurality of first identifiers for a first type of code structureswithin the concentrated code; and c. a first indexed list of the firstidentifiers for the first type of code structure, the first indexed listhaving a plurality of index references and a plurality of upgrade flags,each of the first identifiers in the first list corresponding to atleast one of the index references and one of the upgrade flags in thefirst indexed list, and the computer system having a memory for storingthe concentrated code, an upgrade code and a virtual table therein, thefirst indexed list being stored in the virtual table, the upgrade codealso including a plurality of corresponding code structures, eachincluding a plurality of corresponding identifiers, wherein the methodof dynamically updating the concentrated computer code comprises: a.reading the upgrade code from the memory; b. creating a first upgradelist of a plurality of first corresponding identifiers for a first typeof code structures within the upgrade; c. creating a first indexedupgrade list of the first corresponding identifiers for the first typeof code structures, the first indexed upgrade list including a pluralityof index references, each of the first corresponding identifiers in thefirst upgrade list corresponding to at least one of the index referencesin the first indexed upgrade list; d. creating a concentrated upgradecode, including the steps of scanning the upgrade code and replacingeach occurrence in the upgrade code of a corresponding identifier listedin the first indexed upgrade list with a respective index reference inthe first indexed upgrade list corresponding to the respectivecorresponding identifier; e. storing the first indexed upgrade list inthe virtual table; and f. integrating the concentrated code and theconcentrated upgrade code to form an integrated code, wherein: a. thevirtual table contains an operable part, the operable part beingreferable by the integrated code, b. the first indexed list is stored inthe operable part of the virtual table when the code structure beingexecuted originates from the concentrated code, and c. the first indexedupgrade list is stored in the operable part of the virtual table whenthe code structure being executed originates from the upgrade code. 2.The method of claim 1, wherein the step of creating the first upgradelist of the plurality of corresponding identifiers includes scanning theupgrade code and introducing the corresponding identifiers into thefirst upgrade list.
 3. The method of claim 1, wherein the concentratedcode further includes: a. a second list of a plurality of secondidentifiers for a second type of code structures within the concentratedcode; b. a second indexed list of the second identifiers for the secondtype of code structures, the second indexed list including a pluralityof index references, each of the second identifiers in the second listcorresponding to at least one of the index references in the secondindexed list; and the virtual table has stored therein the secondindexed list, wherein the method of dynamically upgrading theconcentrated code further comprises: a. creating a second upgrade listof a plurality of second corresponding identifiers for the second typeof code structures within the upgrade code; b. creating a second indexedupgrade list of the second corresponding identifiers for the second typeof code structure, the second indexed upgrade list including a pluralityof index references, each of the second corresponding identifiers in thesecond upgrade list corresponding to at least one of the indexreferences in the second indexed upgrade list; c. creating aconcentrated upgrade code, including the steps of scanning the upgradecode and replacing each occurrence in the upgrade code of a secondcorresponding identifier listed in the second indexed upgrade list witha respective index reference in the second indexed upgrade listcorresponding to the respective second corresponding identifier; and d.storing the second indexed upgrade list in the virtual table, andwherein the second indexed list is stored in the operable part of thevirtual table when the code structure being executed originates from theconcentrated code and the second indexed upgrade list is stored in theoperable part of the virtual table when the code structure beingexecuted originates from the concentrated upgrade code.
 4. A method ofdynamically upgrading a concentrated executable computer code in acomputer system, the concentrated code including: a. class, method andfield types of code structures, each type of code structures having aplurality of code identifiers; b. lists of the plurality of codeidentifiers for each of the class, method and field code structureswithin the concentrated computer code; and c. indexed lists of the codeidentifiers for each of the class, method and field code structures,each of the respective indexed lists including a plurality of indexreferences and a plurality of upgrade flags, each of the codeidentifiers in each of the lists corresponding to at least one of theindex references and one upgrade flag in the respective indexed lists,and the computer system including a memory for storing the concentratedcode, an upgrade code and a virtual table therein, the virtual tablehaving the indexed lists stored therein, and the upgrade code alsoincluding corresponding class, method and field types of codestructures, each including a plurality of corresponding identifiers,wherein the method of dynamically upgrading the concentrated codecomprises: a. reading the upgrade code from the memory; b. creatingupgrade lists of the plurality of corresponding identifiers for each ofthe corresponding class, method and field code structures within theupgrade code; c. creating indexed upgrade lists of the correspondingidentifiers for each of the corresponding class, method and field codestructures, each of the respective indexed upgrade lists including aplurality of index references, each of the corresponding identifiers ineach of the upgrade lists corresponding to at least one of the indexreferences in the respective indexed upgrade list; d. creating aconcentrated upgrade code, including the steps of scanning the upgradecode and replacing each occurrence in the upgrade code of acorresponding identifier listed in an indexed upgrade list with arespective index reference in the indexed upgrade list corresponding tothe respective corresponding identifier; e. storing the indexed upgradelists in the virtual table; and f. integrating the concentrated code andthe concentrated upgrade code to form an integrated code, and whereinthe virtual table contains an operable part, the operable part beingreferable by the integrated code, and the index lists are stored in theoperable part of the virtual table when the code structure beingexecuted originates from the concentrated code, and the indexed upgradelists are stored in the operable part of the virtual table when the codestructure being executed originates from the concentrated upgrade code.5. A data storage medium, including machine readable code thereon foruse in a computer system having a memory for storing a concentratedexecutable computer code, an upgrade code and a virtual table therein,the data storage medium having stored thereon the concentrated codeincluding: a. a plurality of types of code structures, each type of codestructures having a plurality of code identifiers; b. a first list of aplurality of first identifiers for a first type of code structureswithin the concentrated code; and c. a first indexed list including aplurality of index references, each of the first identifiers in thefirst list corresponding to at least one of the index references in thefirst indexed list, the data storage medium also having stored thereonthe upgrade code including a plurality of corresponding types of codestructures, each of the corresponding types of code structures having aplurality of corresponding identifiers when the data storage medium isused in the computer system, wherein the data storage medium comprises:a. means for creating a first upgrade list of the plurality ofidentifiers for the first of the types of code structures within theupgrade code as forms the basis of the first list; b. means for creatinga first indexed upgrade list of a plurality of first correspondingidentifiers for the first type of code structure, the first indexedupgrade list including a plurality of index references, each of thefirst corresponding identifiers in the first upgrade list correspondingto at least one of the index references in the first indexed upgradelist; c. creating a concentrated upgrade code, including the steps ofscanning the upgrade code and replacing each occurrence in the upgradecode of a first corresponding identifier listed in the first indexedupgrade list with a respective index reference in the first indexedupgrade list corresponding to the respective first correspondingidentifier; d. means for storing the first indexed list and firstindexed upgrade list in the virtual table; e. means for integrating theconcentrated code and the concentrated upgrade code to form anintegrated code; and f. means for storing the first indexed list in anoperable part of the virtual table referable by the integrated code whenthe code structure of the integrated code being executed originates fromthe concentrated code and for storing the first indexed upgrade list inthe operable part of the virtual table referable by the integrated codewhen the code structure of the integrated code being executed originatesfrom the concentrated upgrade code.
 6. A data processing system havingmeans for reading a concentrated executable computer code and an upgradecode, the concentrated code including: a. a plurality of types of codestructures, each type of code structures having a plurality ofidentifiers; b. a first list of a plurality of first identifiers for afirst type of code structures within the concentrated code; and c. afirst indexed list including a plurality of index references, each ofthe first identifiers in the first list corresponding to at least one ofthe index references in the first indexed list, and the upgrade codeincluding a plurality of corresponding types of code structures, eachcorresponding type of code structures having a plurality ofcorresponding identifiers, the data processing system comprising: a.means for creating a first upgrade list of a plurality of firstcorresponding identifiers for the first type of code structures withinthe upgrade code; b. means for creating a first indexed upgrade list ofthe first corresponding identifiers for the first type of codestructures, the first indexed upgrade list having a plurality of indexreferences, each of the identifiers in the first upgrade listcorresponding to at least one of the index references in the firstindexed upgrade list; c. creating a concentrated upgrade code, includingthe steps of scanning the upgrade code and replacing each occurrence inthe upgrade code of a corresponding first identifier listed in the firstindexed upgrade list with a respective index reference in the firstindexed upgrade list corresponding to the respective first correspondingidentifier; d. means for storing the first indexed list and firstindexed upgrade list in a virtual table; e. means for integrating theconcentrated code and the concentrated upgrade code to form anintegrated code; and f. means for storing the first indexed list in anoperable part of the virtual table referable by the integrated code whenthe code structure of the integrated code being executed originates fromthe concentrated code and for storing the first indexed upgrade list inthe operable part of the virtual table referable by the integrated codewhen the code structure of the integrated code being executed originatesfrom the concentrated upgrade code.
 7. A method of dynamically updatingconcentrated executable computer code in a computer system, the methodcomprising: a. creating a plurality of corresponding identifiers fromthe upgrade code which correspond to code identifiers of code structuresin the concentrated code; b. creating a concentrated upgrade code; c.creating indexed lists for the concentrated code and for theconcentrated upgrade code, such respective indexed lists having aplurality of index references for such code identifiers andcorresponding identifiers respectively; d. storing the indexed lists ina virtual table; and C. integrating the concentrated code with theconcentrated upgrade code to form an integrated code, wherein thevirtual table contains an operable part referable by the integrated codesuch that when a code structure being executed originates from theconcentrated code the indexed list is stored in the operable part of thevirtual table and when a code structure being executed originates fromthe concentrated upgrade code the indexed upgrade list is stored in theoperable part of the virtual table.